*****************************
* SX-PONG (C) Rickard Gune *
*****************************

(This text is mostly a copy of the Video Pong page on my homepage:
http://www.rickard.gunee.com/projects)

---- Introduction ----
The first game I made in color using SX-chips was Tetris. Tetris is an old
Russian computer game where you should try to fit in block into a play-field,
quite simple but really fun. All blocks are built from four bricks (the name
Tetris is derived from the ancient greek word for four: "tetra"), there are
seven combinations of the four bricks. This version is using my PIC Game
System as platform, generating a video signal in software.
The video generating hardware is a 5-bit DA converter built with a few
resistors. Usually the video signal is generated in video games is created
with a dedicated video chips, reading the image data from a graphics memory.
In this project the video signal is calculated in real-time by the
microprocessor as the electron beam sweeps over the screen.

---- How to play the game ----
When the power is turned on the game starts! (was no memory left for a fancy
intro screen or similar). The score is shown left of the gamefield, and the
next block to come is shown in the upper left corner of the screen. As the
blocks fall down, they can be moved sideways by using the joystick (left
gameport on hardware), the fall speed can temporary be increased by moving
joystick down. The fire-button is used to rotate the blocks. When one
horizontal line is full, then it is removed. You get points for full lines
and placed blocks. As you get more points the difficult level is increased
by increased block falling speed. The musics speed is increased as the game
speed increases. You get game over when the playfield level has reached to
the top and there is not room for more blocks.

---- The Software ----
One of the problems for Tetris is the memory required. The size of the
playfield is 16x8 bricks, to be able to keep track of thee 7 different
block kinds (different color for each kind) and also be able to represent
empty area, 3 bits are required for each brick. As one byte is 8 bits I
chose to represent each brick as one nibble (4 bits), making the playfield
64 bytes. I chose to organize the memory making to the top 4 banks of the
memory and letting each memory bank represent two columns. The main game
variables are placed in the first bank, some less used data such as score
and a buffer of the next block and some other misc. stuff are placed in
the second bank. The two remaining banks (except for the top four bytes
of the fourth bank) are used as graphics buffers when outputting data to
the DA. The sound frequency and sample position are stored in the top four
bytes of the fourth bank.

The tune Karboschka is stored in program memory as 52 notes and 52 note
lengths, where the note refers to a frequency table with frequencies according
to the temperated note scale (half notes differs one twelfth root of two in
frequency). There is a 32-sample 4-bit sinus wave in program memory that is
outputted to the audio DA at the pace of the current note translated through
the frequency table. The code outputting the frequency is performed during the
horizontal sync pulse, and the tune is updated at the bottom of the screen
before the vertical sync. As the number of bits used for music is not very
high, it sounds a little bit distorted and not very good, but better than
nothing =)

Most of the game data of the game is stored as one big chunk to be able to
use the program ROM more efficient. This is done by using all the 12 bits
and the iread instruction, which makes it possible to store 50% more data
than by using retlw, but at the cost of speed. It is hard to use 12bit data
efficiently, but to make it easier I chose to separate the gamedata into one
fastmem- and one slowmem- part, where the 8 lower bits of each 12-bit word is
the fastmem and the upper 4 bits are the slowmem. Getting one byte from the
slowmem requires two iread but the fastmem only requires one. Graphics objects
are stored as 4-bit palette values, so is the music, but the font and text
strings are all 8-bit values, so it is quite natural to store the 4-bit data
in the upper part and the 8-bit data in the lower part.

The software is written to run for both PAL and NTSC with almost the same code,
done by making all timing with constants. The constant system selects what TV
system to use. In the code I have also prepared timing for PAL-M and PAL-N but
they are not tested. It is not possible to generate SECAM color video signals
in software with this design, so there is nothing in the code to support it.
Note that the frequency which the chip should be clocked depends on your
TV-system. (This is described more in the system information page)


---- Files in the zip-file ----
The zip-file where this textfile is placed contains the following files:

tetris.src           The source for tetris
tetris_ntsc.src      The source for tetris, same as above but set to NTSC
tetris.hex           Hex-binary of tetris (PAL)
tetris_ntsc.hex      Hex-binary of tetris, same as above but set to NTSC
tetris.jpg           Picture of tetris in action
tetris.txt           This file you are reading now
schematic.png        schematic over the hardware
pcb.png              pcb layout over the hardware


---- Emulators ----
When making this kind of software ios is good to have emulators. There are
unfortunately no emulators yet, but there are some open source emulators for
my previous pic-games. (For example the PIC16F84 emulator by Jesus Arias:
http://bellota.ele.uva.es/~jesus/pic), there are also open source sx-emulators
available (For example Loren Blaney's SxSim: http://www.brouhaha.com/~eric/ubicom/sxsim).
These open source projects are a good start for making your own sx color video
game emulator.


---- Questions? ----
If you have questions about the games, make sure to check out the information on my
electronics project page: http://www.rickard.gunee.com/projects and specially the FAQ
(Frequently Asked Questions) before you ask me.


---- Copyright note ----
SX-Tetris (C) Rickard Gune. This is open source, use this at your own risk ! You may
use the information on this page for your own projects as long as you refer to the
original author (by name and link to authors homepage), don't do it for profit and
don't hurt or harm anyone or anything with it. The author can not be held responsible
for any damage caused by the information on this and related pages.
